%
%~~
%~~  Especificação do Projeto de Formatura
%~~
%
\chapter{Especificação do Projeto de Formatura}
\label{03:chp:especificacaopf}

O projeto de formatura pode ser dividido nos grandes módulos de
arquitetura definidos da seguinte forma: bases de dados, sistema especialista, módulo de
mineração de dados e módulo de extensão do sistema. 

\section{Sistema Especialista}
\label{01:sec:sistemaespecialista}

A primeira parte do projeto consiste no desenvolvimento de um
sistema especialista para diagnóstico médico cuja proposta já é conhecida e
é apresentada com maiores detalhes em \citet{Reggia83}. A arquitetura deste
sistema, representado pela Figura~\ref{img:arquitetura} possui três componentes principais:

\begin{enumerate}
\item O banco de dados é sobre o domínio da aplicação;
\item Mecanismo de inferência é um processo de teste de hipóteses
que imita o raciocínio humano no diagnóstico através do modelo de cobertura
de conjuntos;
\item Interface do usuário que recebe informações e comandos do
usuário para a operação do sistema.
\end{enumerate}

\begin{figure}[htb]
	\center
	\includegraphics[scale=0.8]{images/arquitetura-sistema-especialista.png}
	\caption{Arquitetura do sistema especialista. \citep[p.~440]{Reggia83}}
	\label{img:arquitetura}
\end{figure}

O banco de dados de casos específicos possui uma coleção de
informações que descrevem um problema diagnóstico específico. Essas
informações são adquiridas de maneira sequencial através da interação do
usuário com o sistema em resposta a perguntas geradas pelo sistema
especialista.

O banco de conhecimento possui um formato especial para guardar
informações sobre os transtornos. Esse formato é chamado \textbf{descrição} e
oferece um sumário das manifestações de cada transtorno com informações
detalhadas segundo padrões estabelecidos pelo projetista do banco de
dados. Em geral essas informações estão na sequência: atributo relação valor.

Exemplo:

\begin{verbatim}
	GRIPE

	DOR DE CABEÇA = PRESENTE
\end{verbatim}

Note que os atributos, relações e valores devem ser padronizados e
definidos pelo projetista do banco de dados. Com esta convenção pode-se
aplicar os conceitos de cobertura de conjuntos para a resolução dos
problemas de diagnóstico. Cada \textbf{descrição} é relativa a um transtorno $d_{i}$, e
especifica o conjunto $man(d_{i})$ de todas as manifestações $m_{j}$ causadas pelo
transtorno $d_{i}$. A base de conhecimento define explicitamente o conjunto $\textbf{D}$ de
todos os transtornos assim como $man(d_{i})$ para cada transtorno. O conjunto $\textbf{M}$
é especificado implicitamente através de todas as \textbf{descrições} bem como
a relação $\textbf{C}$ e o conjunto $causas(m_{j})$. Para tornar o conjunto de informações mais  completo adiciona-se na \textbf{descrição} informações
estatísticas de probabilidade de ocorrência em cada manifestação de um
transtorno.

\section{O Mecanismo de Testes de Hipóteses do Sistema}
\label{02:sec:mecanismohipotese}

Para aplicação do modelo de cobertura de conjuntos à relação de um
problema real de diagnóstico médico, o mecanismo de teste de hipótese do
sistema deve estar de acordo com o a dinâmica mais comum enfrentada por
um médico para a formação de hipóteses. Geralmente, o paciente reclama de
um ou mais sintomas principais que o incomodam, o médico então cria uma
hipótese de quais as possíveis doenças dadas as manifestações, formula
então novas perguntas para descobrir novas manifestações, ainda não
conhecidas, a fim de limitar ainda mais o seu conjunto hipótese de doenças
até chegar ao diagnóstico final.

Para imitar essa dinâmica de teste de hipóteses através do modelo de
cobertura de conjuntos, três estruturas de dados são definidas:

\begin{itemize}
\item MANIFS: O conjunto de todas as manifestações conhecidas até o
momento;
\item SCOPE: O conjunto de todas as doenças do sistema capazes de
causar as manifestações conhecidas, ou seja, \textit{causas}(MANIFS);
\item FOCUS: Uma tentativa de solução para as manifestações presentes
em MANIFS. FOCUS é uma coleção de geradores das soluções.
\end{itemize}

Os geradores citados são formas de representar um conjunto de
soluções de maneira compacta, e de forma a facilitar o desenvolver do
algoritmo. Um gerador é análogo a um produto cartesiano com a diferença de
que, ao invés de gerar n-uplas ordenadas, gera conjuntos. Por exemplo, um
gerador poderia ser algo na forma $\{d_{1}, d_{2}\}X\{d_{8}\}$ que gera as soluções $\{d_{1}, d_{8}\}$
e $\{d_{2}, d_{8}\}$.

Com essas estruturas de dados o algoritmo baseado na cobertura de
conjuntos pode realizar o teste de hipóteses. A estrutura FOCUS representa
as tentativas de hipóteses a qualquer momento durante o processo de
resolução do problema. O algoritmo pode ser descrito informalmente da
seguinte maneira \citep{Reggia83}:

\begin{enumerate}[(a)]
\item Adquirir a próxima manifestação $m_{j}$.
\item Adquirir $causas(m_{j})$ da base de conhecimento.
\item MANIFS $\leftarrow$ MANIFS $\cup \, \{ m_{j} \}$.
\item Ajustar FOCUS para acomodar $m_{j}$.
\item Repetir o processo até não haver manifestações adicionais.
\end{enumerate}

Pode-se observar como cada uma das estruturas estabelecidas são
atualizadas durante a execução do algoritmo. Para cada nova manifestação
$m_{j}$ descoberta, MANIFS recebe $m_{j}$, SCOPE é aumentado recebendo todas as
possíveis causas de $m_{j}$, e FOCUS é ajustado para acomodar $m_{j}$ através da
interseção de $causas(m_{j})$ com os conjuntos de doenças presentes nos
geradores, de maneira que todas as explicações que não cobrem o conjunto
MANIFS são eliminadas.

\section{Interface}
\label{03:sec:interface}

Para adquirir informações sobre novas manifestações no algoritmo de
teste de hipóteses o sistema deve gerar perguntas ao operador do sistema
de forma sequencial. As perguntas são relativas à possíveis manifestações
ainda não descobertas e a ordem como são geradas segue uma lógica
utilizando as três estruturas de dados definidas anteriormente.

Considere que uma doença está ativa quando se encontra no conjunto
FOCUS. Para formular uma nova pergunta, o sistema especialista extrai da
DESCRIÇÃO de cada doença ativa o primeiro atributo cujo valor ainda não é
conhecido (os atributos referem-se às informações dos sintomas das
doenças). De todos os atributos candidatos, é selecionado aquele que
aparece no maior número de descrições de doenças possíveis, sendo,
portanto, o objetivo da próxima pergunta.

A razão de selecionar o atributo que aparece o maior número de vezes
é pelo fato de poder gerar uma pergunta capaz de discriminar as soluções
concorrentes presentes no conjunto FOCUS. Além disso, a seleção do
primeiro atributo permite o projetista do banco de conhecimento ter uma
influência no processo de geração das perguntas. O uso dessas duas
técnicas se demonstra eficaz e computacionalmente não custosa devido à
simplicidade das mesmas.

Uma vez que uma questão foi respondida pelo usuário, outro ciclo de
teste de hipóteses se inicia. Isso continua até que não existam mais atributos
das doenças ativas que possuem valores desconhecidos. Esse critério de
parada é uma abordagem arbitrária e pode ser complementado com
perguntas adicionais de protocolo médico de acordo com a necessidade.

\section{Acúmulo dos Dados}
\label{04:sec:acumulodados}

O sistema baseia boa parte de seu funcionamento na hipótese de um
volume extenso de dados médicos e não médicos confiáveis. Para isso, o
trabalho também inclui o acúmulo destes dados respeitando as restrições
de recursos disponíveis e a privacidade dos dados que possam estar
disponibilizados.

A primeira fonte de dados é a base de dados do sistema de saúde brasileiro que
disponibiliza doenças e localidades em que ocorreram, entre outras
informações, através do protocolo FTP publicamente e informações mais
detalhadas com acesso restrito. Essa base de dados corresponde à
internações ocorridas em hospitais e ambulatórios do SUS pelo Brasil entre 1999 e 2004.
Para simplificação, utilizar-se-á os dados correspondentes ao estado
de São Paulo apenas. Uma abrangência maior de Estados não ajudaria a mineração dos
dados pois a grande quantidade de ocorrências de doenças em localidades diferentes não 
aumentam a quantidade de informação que podem ser explicadas em uma mesma localidade, 
apenas multiplica a necessidade de executar o algoritmo de mineração.

Outras possíveis fontes de dados incluem o Hospital das Clínicas e o Hospital Universitário
do campus da Universidade de São Paulo no Butantã, ambos em São Paulo. Foram realizadas visitas,
telefonemas e envio de {\it e-mails} seguindo os protocolos de pedidos de 
dados sobre diagnósticos que cada hospital impõe. Porém, devido a natureza dos dados, a dificuldade
dos hospitais de separarem os dados confidenciais dos não-confidenciais e também ao curto tempo do 
projeto, tais dados não foram obtidos.

Os dados de natureza não médica devem representar eventos ocorridos na mesma localidade e espaço de tempo
onde as ocorrências médicas foram registradas. Foram escolhidos os dados meteorológicos devido a sua fácil
captação e especificamente os dados de temperatura diária pois sua relação com diversas doenças, como a gripe,
é senso comum e significa uma facilidade maior na modelagem de testes de avaliação do sistema.

\section{Extensão do Modelo de Diagnóstico}
\label{05:sec:extensaomodelo}

Uma vez completada a primeira fase do projeto, com um
sistema de diagnóstico já definido e funcional e com dados para sua
utilização, o esforço é concentrado no tratamento de uma base de dados
genérica através da qual se intenciona simular a obtenção de conhecimento
através de experiências prévias, fator que influencia diretamente uma decisão
humana de diagnóstico. Essa base de dados é chamada genérica, pois
contém um histórico de pacientes já diagnosticados, bem como informações
de outras naturezas que podem estar associadas as causas de doenças.

O tratamento dessa base foi feito segundo as etapas do processo de
KDD já definidas, com o objetivo de alcançar a descoberta de padrões que
reflitam em novos conhecimentos. O projeto do sistema permitirá a futura implementação 
da incorporação dinâmica de novos dados onde os modelos encontrados terão participação 
complementar no mecanismo de inferência do sistema. 

Para o mecanismo de mineração de dados a intenção é optar por um modelo bastante simplificado
a princípio para não comprometer o tempo de execução do projeto e para comprovar a eficácia do projeto
proposto e depois, com os mesmos dados, utilizar métodos que apresentem resultados mais significativos. 
O problema inerente à escolha do mecanismo envolve como estão configuradas as entradas deste e
qual a forma do resultado esperado. A partir dos diversos mecanismos estudados em \citet{Fayyad96} e aprofundados
em \citet{Witten05} optou-se pela geração de regras de relacionamento entre os dados de entrada de forma que se 
possa controlar a taxa de erro da regra versus o seu grau de generalização. 

O mecanismo simplificado para a primeira parte do projeto foi o algoritmo definido em \citet{Witten05} como {\bf 1R} e especificado na Seção~\ref{classificacao}.Ele simplesmente testa todas os pares de atributos entre os dados de treinamento e define tal como uma regra de relacionamento com taxa de acerto de acordo com o que foi percebido. Como o objetivo é gerar regras de relacionamento, elas não precisam cobrir todos as ocorrências. Assim, é definido uma taxa de acerto mínima para limitar o número de regras criadas nos dados de treinamento, o que os autores \citet{Witten05} estimam arbitrariamente como cerca de 80\% 
de taxa de erro.

Os dados de temperatura numéricas trazem pouca informação para o observador e são representadas em muitos valores. Para isso, se dividiu a média das temperaturas mensais em três classes distintas: para valores maiores que 24 graus celsius, o valor será \textquoteright alta\textquoteright; para valores menores que 18 graus celsius, o valor será \textquoteright baixa\textquoteright; todos os valores entre estes \textquoteright média\textquoteright. Como explicado por \citet{Witten05}, ao se trabalhar com dados discretos e dados numéricos o algoritmo ao invés de associar regras entre valores de atributos, irá relacionar os valores de dados discretos, neste caso a temperatura, com faixas de valores dos dados numéricos (ocorrências mensais). 

A divisão dos dados em treinamento e testes irá seguir o esquema de \textit{ten-folding} explicitado na Seção~\ref{tenfolding}. A resposta para se os dados da temperatura terão relação ou não com os dados de ocorrências estarão na taxa de erro médio entre as amostras estudadas. A taxa de erro quando o conjunto de dados de teste é muito grande tendendo ao infinito deve tender a zero no caso de nenhuma relação existir. Caso contrário, irá tender a algum valor definido representando a \textquoteright taxa de relacionamento entre os atributos\textquoteright.